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BACKGROUND OF THE INVENTION 

1. The Field of the Invention 

[0001] The present invention relates to managing processes on a computer system. 
More specifically, the present invention relates to mechanisms for detecting termination and 
providing information related to termination of a computer system process. 

2. Background and Related Art 

[0002] Computers have revolutionized the way we work and play. There are an 
enormous variety of functions and applications that may be implemented by a general 
purpose computing system in response to the execution of a software application. The 
utility and functionality of the computing system does, however, rely on the proper coding 
of the source code that was compiled or interpreted into the binary instructions that are 
actually executed by the processor. If there is a coding error, this will often result in a 
deviation from expected functionality. 

[0003] Extraordinary efforts are currently in place to reduce the number of unexpected 
performance deviations in many software programs before and after the software application 

^ are shipped to market. However, the creativity of software programmers and designers has 
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g led to increasingly complex and powerful software applications. As the complexity of the 

o4$**^Z software application increases, so often does the number of lines of source code needed to 
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cause a software application to deviate from expected performance. Further, there is always 
O some potential for the instructions of a software application to cause the software application 

to terminate without providing any information related to the cause of the termination 
(hereinafter referred to as "undetected termination"). 
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[0004] Undetected termination of a software application can occur when the software 
application includes a default behavior for handling otherwise unhandled exceptions 
generated by the software application. Deviation from expected performance at run-time 
(e.g., due to execution of an invalid instruction) can cause an error, often referred to as an 
"exception". When a code layer that caused an exception does not include instructions for 
handling the exception, the exception can be propagated to other code layers until 
instructions for handling the exception are located. For example, a software application may 
execute an invalid instruction that attempts to write data to memory address zero. Since 
computer systems typically do not allow access to memory address zero, execution of the 
invalid instruction results in an access violation exception. If the software application does 
not include appropriate instructions for handling the access violation exception, the access 
violation exception can be referred to as an "unhandled" exception (i.e., the software 
application does not handle the access violation exception) and can be propagated to an 
operating system code layer. 

[0005] When the operating system code layer receives an unhandled exception, the 
operating system code layer can handle the unhandled exception by launching a debugger or 
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£j crash monitor that provides information related to the unhandled exception. For example, a 
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us £ I > & Z debugger or crash monitor can provide register values, a memory dump, and/or an event log 

2 d S o 5 £ that represent the state of the computer system at the time the unhandled exception occurred, 

g pa < <j This is beneficial as a developer or user of the software application is provided information 
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that may be useful in determining the cause of the unhandled expectation. Unfortunately, it 
may be difficult for a software application that caused an unhandled expectation to recover 
and resume executing instructions. For example, the software application may freeze and 
there may be not way to return execution back to the software application. 
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[0006] Accordingly, software developers can include instructions for catching and 
handling exceptions a software application might generate or otherwise encounter. Many 
software applications are designed to catch at least common exceptions and appropriately 
handle the common exceptions in a manner that allows the software application to continue 
functioning. Unfortunately, some software developers may lack the desire and/or 
knowledge to implement instructions that check for all possible handles exceptions a 
software application might generate or otherwise encounter. On the other hand, more 
conscientious software developers may include substantial error checking and exception 
handling code, in an attempt to handle all possible exceptions an application program might 
generate or otherwise encounter. However, there is always some potential for even a 
conscientious software developer to develop a software application that lacks appropriate 
instructions for handling at least some exceptions. 

[0007] Thus, during the execution of a software application there is always a possibility 

that an exception will go unhandled by exception handling mechanisms expressly included 

in the software application. As a result, some compilers insert code into software 

^ applications that handle exceptions in a default manner when the exceptions are not 
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Q otherwise handled by expressly included exception handling mechanisms. For example, it 

p4 3 1 £ Z ma y be that a software application developed in C++ source code does not include 
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§ 3 > ci S £ instructions for catching and handling C++ exceptions. Thus, when the software application 
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ZESSSS generates a C++ exception, the C++ exception is handled in the default manner. The default 
manner can include returning execution to a "main" function that attempts to handle the 



O exception. If the main function cannot handle the exception, the main function calls an 



"exit" function causing the software application to terminate. That is, the main function 
handles the C++ exception by terminating the software application. 

- Page 4 - Docket No. 13768.438 



[0008] Since the main function handles the C++ exception, the C++ exception is not 
propagated to other code layers. Thus, there is limited, if any, chance for an operating 
system code layer to detect the C++ exception as an unhandled exception. Accordingly, the 
operating system code layer does not invoke a debugger or crash monitor and the software 
application is terminated without providing information related to the cause of the 
termination. 

[0009] Undetected termination of a software application can also occur when the 
software application includes a default behavior for handling appropriate input. For 
example, a software application may include a conversion function that converts a text 
representation of message length (e.g., in bytes) to a positive integer. However, the 
developer of the software application may have failed to consider the possibility of receiving 
a negative message length and thus may simply pass a negative message length to the 
conversion function. The conversion function's behavior upon receiving a negative message 
length may be to call an exit function, which terminates the software application. Thus, if 
the conversion function was called with a message length of negative one, the conversion 
^ function would cause the software application to terminate. However, little, if any, 

£3 information related to the termination would be provided to a user or developer of the 
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£ « £ w < «j developer may lack access to the source code (e.g., in C++, C#, or Visual Basic) for a 
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[0010] Although a developer could potentially re-code the conversion function, the 



software application. Instead, the software developer may have access only to machine 
and/or object instructions (e.g., an executable program or dynamic link library ("DLL")) 
generated as a result of compiling the source code. Thus, even if a developer has the desire, 
ability, and appropriate tools for re-coding a function to provide information related to the 

- Page 5 - Docket No. 13768.438 



termination of a software application, the developer may nonetheless be prevented from 
implementing the functionality. 

[0011] When a software application is executed, one or more process may be loaded into 
system memory. Many processes are loaded into system memory to perform automated 
tasks that do not require user-input to function. For example, a loaded process can monitor 
ports of a computer system for incoming electronic messages. Many operating systems (as 
well as other software systems) include the functionality to display a "task list" of processes 
that are loaded in memory. For example, in some Microsoft® Windows® environments, a 
computer system user or administrator can activate a key combination of the "Ctrl", "Alt", 
and "Delete" keys to display a task list. Thus, a user or administrator can view processes 
(even some background processes) running on a corresponding computer system. 
[0012] Unfortunately, due to default exception handling and/or the default behavior of a 
function, undetected termination of memory resident processes can occur. That is, 
termination of the process can occur without an error message being presented at the 
computer system (either from the terminating process or the operating system). Thus, a user 
^ or administrator may become aware that the terminated process is no longer running only 

^ after actions typically performed by the process (e.g., automatically checking for electronic 
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2 < £ §j Z ma ^ messa g es ) do not occur. Accordingly, what would be advantageous are mechanisms 
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BRIEF SUMMARY OF THE INVENTION 
[0013] The foregoing problems with the prior state of the art are overcome by the 
principles of the present invention, which are directed towards systems, methods, and 
computer program products for detecting termination and providing information related to 
termination of a computer system process. A computer system includes system memory 
(e.g., Random Access Memory ("RAM")) and a storage location (e.g., a magnetic hard 
disk). The computer system loads a termination function, such as, for example, an abort, 
exit, or terminate function, into system memory. The memory resident termination function 
includes termination instructions that, when executed, cause a calling process to terminate 
without providing information related to a termination event that caused the calling process 
to terminate. 

[0014] The computer system redirects the functionality of the memory resident 
termination function to a memory resident detour function. Functionality of the memory 
resident termination function is redirected such that when the memory resident termination 
function is called, instructions of the memory resident detour function are executed. The 
memory resident detour function includes an invalid instruction that, when executed, causes 
§ an exception. The invalid instruction may cause an exception having an increased 
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layer). Through redirection of a memory resident termination function, the functionality of 
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gj t w < 2 an application program can be altered without having to recompile the application program 



and/or the termination function. Accordingly, a developer may be able to alter the 



O functionality of a memory resident termination function even if the developer lacks access to 

the source code for the application program and/or the termination function. For example, 
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the developer can alter the functionality of an "exit" function to cause an exception having 
an increased chance of propagating to an operating system code layer. 
[0015] A memory resident process detects a termination event, such as, for example, a 
main function receiving a C++ exception that can not be handled or a function receiving 
invalid input. Accordingly, the memory resident process calls the memory resident 
termination function in an attempt to terminate the memory resident process. The computer 
system redirects the call from the memory resident termination function to the memory 
resident detour function. The computer system executes the invalid instruction included in 
the detour function to generate an exception. The invalid instruction can generate an 
exception that has an increased chance of being propagated to another code layer. For 
example, the invalid instruction can be an instruction that causes an access violation by 
attempting to write data to memory address zero. 

[0016] Accordingly, the generated exception can be received at another code layer, for 
example, an operating system code layer, as an unhandled exception (i.e., an exception that 
was not handled at an application code layer). It may be that the unhandled exception is 
^ caught by an unhandled exception catcher at the operating system code layer. In response, 

Q the unhandled exception catcher can invoke a debugger or crash monitor that gathers 
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S d 2 o 5 £ memory resident process. Thus, through redirection to a detour function, termination 
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S s t w < ^ information, that would otherwise not be gathered, can be used to determine the cause of 
^ < " process termination. 

O [0017] Additional features and advantages of the invention will be set forth in the 

description that follows, and in part will be obvious from the description, or may be learned 
by the practice of the invention. The features and advantages of the invention may be 
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realized and obtained by means of the instruments and combinations particularly pointed out 
in the appended claims. These and other features of the present invention will become more 
fully apparent from the following description and appended claims, or may be learned by the 
practice of the invention as set forth hereinafter. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
[0018] In order to describe the manner in which the above-recited and other advantages 
and features of the invention can be obtained, a more particular description of the invention 
briefly described above will be rendered by reference to specific embodiments thereof which 
are illustrated in the appended drawings. Understanding that these drawings depict only 
typical embodiments of the invention and are not therefore to be considered to be limiting of 
its scope, the invention will be described and explained with additional specificity and detail 
through the use of the accompanying drawings in which: 

[0019] Figure 1 illustrates an example of computer system architecture and associated 
modules and data structures for detecting termination and providing information related to 
termination of a computer system process in accordance with the principles of the present 
invention. 

[0020] Figure 2 illustrates a flowchart of a method for detecting termination and 
providing information related to termination of a computer system process in accordance 
with the principles of the present invention. 

[0021] Figure 3 illustrates a suitable operating environment for the principles of the 
Q present invention. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 



[0022] The present invention extends to methods, systems, and computer program 
product for detecting termination and providing information related to termination of a 
computer system process. A computer system loads a termination function, such as, for 
example, an abort, exit, or terminate function, into system memory such that the termination 
function become memory resident. The memory resident termination function includes 
termination instructions that, when executed, cause a calling process to terminate without 
providing information related to a termination event that caused the calling process to 
terminate. The computer system redirects the functionality of the memory resident 
termination function to a memory resident detour function such that when the memory 
resident termination function is called, instructions of the memory resident detour function 
are executed. The memory resident detour function includes an invalid instruction that, 
when executed, causes an exception that can be used to provide termination information 
related to a termination event that caused the process to terminate. 

[0023] A memory resident process (e.g., the application process) detects a termination 
^ event (e.g., handling a C++ exception according to compiler provided default behavior) and 
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§ the memory resident process calls the termination function. The computer system redirects 
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m d S o 5 1 function. Accordingly, the computer system executes the invalid instruction to generate an 
£ g g S < a exception. For example, the computer system may execute an instruction that causes an 
|j < " access violation by attempting to write data to memory address zero. 

O [0024] Embodiments of the present invention may comprise a special purpose or 

general-purpose computer including various computer hardware and software, as discussed 
in greater detail below. In particular, embodiments within the scope of the present invention 
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include computer-readable media for carrying or having computer-executable instructions or 
data structures stored thereon. Such computer-readable media can be any available media 
that can be accessed by a general purpose or special purpose computer. By way of example, 
and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, 
CD-ROM or other physical storage media, such as optical disk storage, magnetic disk 
storage or other magnetic storage devices, or any other medium which can be used to carry 
or store desired program code means in the form of computer-executable instructions or data 
structures and which can be accessed by a general purpose or special purpose computer. 
[0025] When information is transferred or provided over a network or another 
communications connection (either hardwired, wireless, or a combination of hardwired or 
wireless) to a computer, the computer properly views the connection as a computer-readable 
medium. Thus, any such connection is properly termed a computer-readable medium. 
Combinations of the above should also be included within the scope of computer-readable 
media. Computer-executable instructions comprise, for example, instructions and data 
which cause a general purpose computer, special purpose computer, or special purpose 
^ processing device, such as a GPU, to perform a certain function or group of functions. 
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§ [0026] Although not required, the invention will be described in the general context of 
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& £ 1 ^ & 2 computer-executable instructions, such as program modules, being executed by computer 
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types. Computer-executable instructions, associated data structures, and program modules 



O represent examples of the program code means for executing acts of the methods disclosed 

herein. 
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[0027] In this description and in the following claims, a "computer system" is defined as 
one or more software modules, one or more hardware modules, or combinations thereof, that 
work together to perform operations on electronic data. For example, the definition of 
computer system includes the hardware components of a personal computer, as well as 
software modules, such as the operating system of the personal computer. The physical 
layout of the modules is not important. A computer system may include one or more 
computers coupled via a network. Likewise, a computer system may include a single 
physical device (such as a mobile phone or Personal Digital Assistant "PDA") where 
internal modules (such as a memory and processor) work together to perform operations on 
electronic data. 

[0028] Those skilled in the art will appreciate that the invention may be practiced with 
many types of computer system configurations, including, personal computers, laptop 
computers, multi-processor systems, minicomputers, mainframe computers, and the like. 
The invention may also be practiced in distributed system environments where local and 
remote computer systems, which are linked (either by hardwired links, wireless links, or by 
^ a combination of hardwired and wireless links) through a network, both perform tasks. In a 

§ distributed system environment, program modules and associated data structures may be 
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& 2 1 * %Z located in both local and remote memory storage devices. 

S jSolfc [0029] Turning now to Figure 1, Figure 1 illustrates an example of a computer system 
2 g h a 2 5 architecture 1 00 and associated modules and data structures detecting termination and 
^ < w providing information related to termination of a computer system process. The rectangular 
O elements in computer system architecture 100 (e.g., operating system process 109, exception 

catcher 108, detour function 127, and debugger 107) represent executable modules that 
facilitate detecting termination and providing information related to termination of a 
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computer system process (e.g., application process 106). The scrolled elements (e.g., input 
131 and termination information 133) represent data that is processed by the executable 
modules to detect termination and provide information related to termination of a computer 
system process. Accordingly, the executable modules and scrolled elements depicted in 
computer system architecture 1 00 cooperatively interact to implement the principles of the 
present invention. 

[0030] Computer system architecture 100 can receive input (e.g., input 131) that causes 
the execution of application programs (e.g., application program 105) stored at a storage 
device (e.g., storage 102). Executed application programs can cause application processes 
to be loaded into system memory (e.g., system memory 101). For example, as illustrated by 
arrow 153, computer system architecture 100 can receive input 131 causing application 
program 106 to load into system memory 101. Input 131 can be user-input (e.g., received at 
a keyboard or mouse) or can be input from another computer system (e.g., a computer 
system that is network connectable to computer system architecture 100). Storage 102 and 
system memory 101 can exchanged information over link 141, which can be a portion of a 
system bus, a portion of a local area network ("LAN"), and/or a portion of a Wide Area 

w 

g Network ("WAN"). 

pt2%%£Z [0031] Input 131 can include manually entered input and/or automatically generated 
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SdSSgfc input. For example, manually entered input at computer system architecture 100 (or a 
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^ § E ^ 2j 3 network connectable computer system) can cause execution of an application program at 
jjj w computer system architecture 100. On the other hand, computer system architecture 100 (or 
O some other network connectable computer system) can be configured to automatically 

execute an application program at computer system architecture 100 when a specified event 
occurs (e.g., at specified intervals, at system startup, etc). Accordingly, when a specified 
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interval occurs, an application program is executed at computer system architecture 100 
without user intervention. 

[0032] Execution of an application program can cause one or more processes to be 
loaded into system memory. For example, execution of application program 1 05 can cause 
application process 106 (and potentially other application processes) to be loaded into 
system memory 101 (e.g., Random Access Memory). A process loaded into system memory 
can be referred to as a "memory resident process". Accordingly, application process 106 
can be referred to as a memory resident process. 

[0033] Application program 105 can be an executable program that was compiled from 

source code. For example, application program 105 may be the result of a C++ compiler 

compiling C++ source code. Thus, processes spawned from application program 105 may 

generate C++ exceptions. Application program 105 may also be compiled to include one or 

more functions that respond to invalid input by attempting to terminate a calling process. 

For example, source function 112 can include instructions (e.g., termination call 113) that 

call an exit function in response to receiving improper input, such as, for example, receiving 

^ input of an improper data type (e.g., receiving a negative value for a length), 

w 

g [0034] Application program 105 can be compiled to include detours library 123, which 
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Pi 1 1 * lj 2 enables in memory redirection of functions called by application program 105. When an 
pq i£oo£ application including detours library 123 is loaded, the application can check a registry to 



■ § £ « <j «j determine if in memory redirection is active. For example, when application process 106 is 
loaded, application process 106 can check registry 132. Registry 132 can include one or 



O more registry entries, such as, for example, registry entry 133. Registry entries can include 

name/value pairs. For example, registry entry 133 includes identifier 134 that identifies 
registry entry 133 and a corresponding value 136 representing a value for registry entry 133. 
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[0035] Registry entry 133 can be an entry that indicates whether or not in memory 
redirection is active. For example, identifier 134 may be a "CrashOnUnexpectedExit" key 
that indicates registry entry 133 is the registry entry to check to determine if in memory 
redirection is active. Value 136 can be a corresponding value set, for example, to "On or 
"Active" when in memory redirection is active and set, for example, to "Off or "Inactive" 
when in memory redirection is not active. An administrator or user of computer system 
architecture 100 can utilize a registry access module to appropriately set value 136. When 
in memory redirection is active, an application process can redirect a call that would 
otherwise go to a target function to a detour function. 

[0036] Source function 112 can be a module or subroutine that is called to execute a 
portion of the functionality of application process 106. Source function 112 can include 
default catch instructions that prevent specified exceptions (e.g., exceptions that may not be 
appropriately handled by legacy debuggers) from being propagated to other code layers. 
When source function 112 detects one of these specified exceptions, source function 112 can 
execute termination call 113 that causes execution to jump to termination function 114. 
^ Accordingly, in response to one of the specified exceptions, termination instructions 1 16 are 

£j executed to terminate application process 106 (the calling process). Termination 

2 g w 5 

2 ^5 & Z instructions 116 can be instructions that terminate application process 106 without providing 

S S > o d £ an y termination information (e.g., register values, memory dumps, events logs, etc.) related 
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Zgsg^ to the specified exception that caused application process 106 to terminate. 

[0037] Operating system process 1 09 can monitor for otherwise unhandled exceptions at 
an operating system code layer. When an application program that caused an exception does 
not handle the exception, the otherwise unhandled exception can be propagated to other 
code layers, including the operating system code layer. When an otherwise unhandled 
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exception is detected at the operating system code layer, operating system module 109 can 
invoke exception catcher 108 (e.g., a user-configured unhandled exception catcher) to 
attempt to handle the exception. In response to detecting an otherwise unhandled exception, 
exception catcher 108 can invoke a debugger or crash monitor. 

[0038] For example, exception catcher 108 can execute debugger 107 causing debug 
process 152 to load into system memory 101. Debug process 152 can be a debug or a crash 
monitor process that is configured to gather termination information (e.g., register values, 
memory dumps, events logs, etc.) related to an otherwise unhandled exception and/or 
termination of a memory resident process. Debug process 152 can present gathered 
termination information at an output device and/or store termination information (e.g., at 
storage 102) for subsequent presentation at an output device. For example, debug process 
152 can send termination information 133 to a computer display device and/or a log file. 
[0039] As depicted in Figure 1, detour function 127 is included in application process 
106. Detour function 127 includes invalid instruction 128 that, when executed, results in an 
exception. The resulting exception can be an exception that has an increased likelihood of 
^ being propagated to the operating system code layer (e.g., an exception resulting from an 

attempt to write to memory address zero). Accordingly, in response to the execution of 
exception instruction 128, exception catcher 108 (or a module in communication with 
§ 3 2 5 5 1, operating system module 109) can load debug process 152 into system memory 101. 
% jjj f: 2 < | [0040] Figure 2 illustrates a flowchart of a method 200 for detecting termination and 
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providing information related to termination of a computer system process. The method 200 



O will be discussed with respect to the executable modules and data structures depicted in 

computer system architecture 100. The method 200 includes a functional result oriented 
step for configuring a termination function to execute an exception instruction that provides 
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termination information associated with a termination event (step 206). Step 206 can 

include any corresponding acts for configuring a termination function to execute an invalid 

instruction that provides termination information associated with a termination event. 

[0041] Step 206 can include a corresponding act of altering source code such that a 

termination event (e.g., an exception caught by a compiler included default exception 

catcher) causes the invalid instruction to be executed. When a developer has access to the 

source code for a termination function, the developer can alter the source code to create a 

customized termination function that includes the invalid instruction. Alternately, when the 

developer has access to source code for an application program that calls the termination 

function, the developer may be able to replace the call to the termination function with a call 

to a detour function that includes the invalid instruction. For example, a developer with 

access to appropriate source code (e.g., compiler source code that includes a default 

exception catcher in an application program,) can alter termination function 114 and/or 

application program 105 to include an appropriate invalid instruction (e.g., invalid 

instruction 128). Accordingly, source code can be altered such that there is an increased 

^ chance of detecting and providing termination information related to a termination event 

w 

g and/or the termination of processes spawned from the application program 105. 
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S^ODfc termination event (e.g., an exception caught by a default exception catcher) causes the 
Z B £ |I § invalid instruction to be executed. When a developer has access to the binary code for a 
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termination function, the developer can alter the binary code to create a customized 
termination function that includes the invalid instruction. Alternately, when the developer 
has access to binary code for an application program that calls the termination function, the 
developer can replace the call to the termination function with a call to a detour function that 
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includes the invalid instruction. For example, a developer with access to appropriate binary 
code can alter termination function 114 and/or application program 105 to include an 
appropriate invalid instruction (e.g., exception instruction 128). Accordingly, binary code 
can be altered such that there is an increased chance of detecting and providing termination 
information related to a termination event and/or the termination of processes spawned from 
the application program 105. 

[0043] Step 206 can also include a corresponding act of altering entries in a source 

library to point to a detour library. For example, a developer with access to a source 

Dynamic Link Library ("DLL") can alter import entries in the source DLL to redirect calls 

to the source DLL to a detour DLL that includes the invalid instruction. Redirection to the 

detour DLL can include replacing the name of the source DLL in an import table before the 

source DLL is loaded into system memory or replacing entries in a jump table after the 

source DLL is loaded into system memory. Accordingly, libraries can be redirected such 

that there is an increased chance of detecting and providing termination information related 

to a termination event and/or the termination of processes spawned from the application 

j>h program 105. 
w 

g [0044] However, in the method illustrated in Figure 2, step 206 includes a corresponding 
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jj * 5 & ~ act of loading a termination function into system memory (act 206). Act 206 can include a 

S j £ g 5 > computer system loading a termination function having termination instructions that, when 
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£ S C ^ 1 § executed, cause a calling process to terminate without providing information related to a 
g M termination event (e.g., default behavior calling an exit function) that caused the calling 
O process to terminate. For example, computer system architecture 100 can load application 

process 106, which includes termination function 114, into system memory 101. 

Termination function 114 includes termination instructions 116, which, when executed, 

- Page 19 - Docket No. 13768.438 



cause application process 106 to terminate but do not provide information related to the 
termination of application process 106. Termination function 114 can be any of a wide 
variety of termination functions, such as, for example, terminate, abort, exit, _exit, cexit, 
c exit, _amsgexit, and ExitProcess functions, called as a last resort when a situation (e.g., 
an exception or an in valid input value) is not otherwise appropriately handled. 
[0045] In the method illustrated in Figure 2, step 206 includes a corresponding act of 
redirecting the termination function to an invalid instruction that provides termination 
information (act 202). Act 202 can include a computer system redirecting the functionality 
of the termination function to a memory resident detour function such that when the 
termination function is called, instructions of the detour function are executed. The detour 
function can include an invalid instruction that, when executed, causes an exception that can 
be used to provide termination information related to a termination event that otherwise 
cause a calling process to terminate. For example, when in memory redirection is active, 
computer system 101 can execute detour call 126 to redirect (e.g., through a jump 
instruction) the functionality of termination function 114 (e.g., an exit function) to detour 

^ function 127 (e.g., that includes instructions for causing an access violation). Detour call 

pq 

§ 126 can be included at or near the beginning of termination function 1 14 such that execution 

c*%%*&Z is redirected to detour function 127 before termination instructions 116 are executed. 
Sd^opfc Accordingly, when source function 112 executes termination call 113, execution can be 
redirected (through detour call 126) to detour function 127. 



< < 



[0046] Method 200 includes an act of a memory resident process detecting a termination 
event (act 203). Act 203 can include a memory resident process at a computer system 
detecting a termination event. A termination event can be an exception or other event that 
has a decreased likelihood of being propagated to other software layers resident in system 
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memory 101. For example, a termination event can be an exception that is processed by 
default compiler included instructions (e.g., instructions that prevent propagation of a C++ 
exception) or a call to termination function as a result of invalid input to a function. 
[0047] During execution of source function 112, application process 106 can detect a 
termination event that is to terminate application process 106. For example, application 
process 106 may detect a C++ exception that is processed by default compiler included 
behavior in a main function. It may be that a legacy debugger (such as debugger 107) can 
not appropriately handle C++ exceptions and the default compiler included behavior thus 
prevents propagation of C++ exceptions 

[0048] Method 200 includes an act of the memory resident process calling the 
termination function (act 204). Act 204 can include a memory resident process at a 
computer system calling the termination function. For example, in response to the detected 
termination event, source function 112 can execute termination call 113 to call termination 
function 114. During execution of termination function 114, detour call 126 can be 
executed and detour function 127 called. Accordingly, execution is redirected (within 
^ system memory 101) from termination function 1 14 to detour function 127. 

9 

[Jj [0049] Method 200 includes an act of executing the invalid instruction to provide 



z 
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oj 1 1 > & Z termination information related to the detected termination event (act 205). Act 205 can 
2 d > o 5 1 include a computer system executing the invalid instruction to provide termination 



i ( /) ^ O H W 

; g £ w < 2 information related to the detected termination event, in response to the termination function 

^ g O H 
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being called. For example, during execution of detour function 127, computer system 



O architecture 100 can execute invalid instruction 128. Executing invalid instruction 128 (e.g., 

attempting to write data to memory address zero) can generated an exception that has an 
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increased likelihood of being propagated to other code layers, such as, for example, to an 
operating system code layer monitor by operating system process 109. 
[0050] Accordingly, exception catcher 108 can detect an exception resulting from 
execution of invalid instruction 128. Exception catcher 108 can cause debug process 152 
(e.g., a debugger or crash monitor process) to launch. For example, in response to the 
execution of invalid instruction 128, exception catcher 108 (or some other operating system 
process in communication with operating system process 109) can execute debugger 107. 
As illustrated by arrow 154, execution of debugger 107 can cause debug process 152 to be 
loaded in to system memory 101. Execution of an invalid instruction can also cause 
termination information to be gathered by a debug process. For example, debug process 1 52 
can gather termination information (e.g., register values, memory dumps, and event logs) 
related to the termination of application process 106. 

[0051] Debug process 1 52 can transfer gathered termination information for presentation 
at an output device and/or can store gathered termination information for later presentation. 
For example, computer system architecture 100 can transfer termination information 133 to 
a computer monitor. Accordingly, a memory resident termination function can be redirected 

g to a memory resident detour function. This increases the chances of detecting and providing 

c^ 2 - 
2 g w 3 

& 2 1 * $ Z termination information related to a termination event and/or the termination of processes. 

W 2 J h I 3 

Q | H w H g 

SSSSifc" F° r example, termination information can be provided even when a C++ exception or 

H o 3 J w u 

1 1 2 < 2 invalid input to a function would otherwise result in undetected process termination. 
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[0052] It may also be that in memory redirection is at some time deactivated. For 



O example, a user or administrator can set value 136 to "off or "inactive". Accordingly, 

during execution of a termination function detour calls are bypassed. For example, when in 
memory redirection is inactive, calls to termination function 114 result in the execution of 
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termination instructions 116 (since detour call 126 is bypassed). Thus, in memory 
redirection can be reconfigured without having to reload a process in to system memory. 
For example, when in memory redirection is active, detour call 126 is executed. On the 
other hand, when in memory redirection is inactive, detour call 1 26 is bypassed. 
[0053] In memory redirection can be in inactivated as part of the normal termination of a 
memory resident process. This significantly reduces the possibility of normal termination 
(e.g., in response to user or administrator commands) causing an inappropriate call to a 
detour function. 

[0054] Figure 3 illustrates a suitable operating environment for the principles of the 

present invention. Figure 3 and the following discussion are intended to provide a brief, 

general description of a suitable computing environment in which the invention may be 

implemented. With reference to Figure 3, an example system for implementing the 

invention includes a general-purpose computing device in the form of computer system 320. 

[0055] Computer system 320 includes a processing unit 321, a system memory 322, and 

a system bus 323 that couples various system components including the system memory 322 

^ to the processing unit 321. Processing unit 321 can execute computer-executable 

w 

§ instructions designed to implement features of computer system 320, including features of 
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Pi % 1 1 §Z the present invention. The system bus 323 may be any of several types of bus structures 
§ d £ 5 5 £ including a memory bus or memory controller, a peripheral bus, and a local bus using any of 
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S S C « § ^ a vaf i et y °f bus architectures. The system memory includes read only memory ("ROM") 
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324 and random access memory ("RAM") 325. A basic input/output system ("BIOS") 326, 



O containing the basic routines that help transfer information between elements within the 

computer 320, such as during start-up, may be stored in ROM 324. 
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[0056] The computer system 320 may also include a magnetic hard disk drive 327 for 
reading from and writing to a magnetic hard disk 339, a magnetic disk drive 328 for reading 
from or writing to a removable magnetic disk 329, and an optical disk drive 330 for reading 
from or writing to removable optical disk 331, such as, or example, a CD-ROM or other 
optical media. The magnetic hard disk drive 327, magnetic disk drive 328, and optical disk 
drive 530 are connected to the system bus 323 by hard disk drive interface 352, magnetic 
disk drive-interface 333, and optical drive interface 334, respectively. The drives and their 
associated computer-readable media provide nonvolatile storage of computer-executable 
instructions, data structures, program modules, and other data for computer system 320. 
Although the example environment described herein employs a magnetic hard disk 339, a 
removable magnetic disk 329 and a removable optical disk 331, other types of computer 
readable media for storing data can be used, including magnetic cassettes, flash memory 
cards, digital versatile disks, Bernoulli cartridges, RAMs, ROMs, and the like. 
[0057] Program code means comprising one or more program modules may be stored on 
the hard disk 339, magnetic disk 329, optical disk 331, ROM 324 or RAM 325, including an 
^ operating system 335, one or more application programs 336, other program modules 337, 

s 

3 and program data 338. A user may enter commands and information into the computer 

2 gj u g 

& 2 5 5 Sj Z system 320 through keyboard 340, pointing device 342, or other input devices (not shown), 

w 2 J h g 5 

§ d > o 5 1 such as, for example, a microphone, joy stick, game pad, scanner, or the like. These and 

% g g 2 < 3 other input devices can be connected to the processing unit 321 through serial port interface 

g 60 346 coupled to system bus 323. Alternatively, input devices can be connected by other 



O interfaces, such as, for example, a parallel port, a game port, a universal serial bus ("USB") 

port, or a Fire Wire port. A monitor 347 or other display device is also connected to system 
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bus 323 via video adapter 348. Computer system 320 can also be connected to other 
peripheral output devices (not shown), such as, for example, speakers and printers. 
[0058] Computer system 320 is connectable to networks, such as, for example, an 
office-wide or enterprise-wide computer network, an intranet, and/or the Internet. Computer 
system 320 can exchange data with external sources, such as, for example, remote computer 
systems, remote applications, and/or remote databases over such a network. 
[0059] Computer system 320 includes network interface 353, through which computer 
system 320 receives data from external sources and/or transmits data to external sources. As 
depicted in Figure 3, network interface 353 facilitates the exchange of data with remote 
computer system 383 via link 351. Link 351 represents a portion of a network, and remote 
computer system 383 represents a node of the network. 

[0060] Likewise, computer system 320 includes serial port interface 346, through which 
computer system 320 receives data from external sources and/or transmits data to external 
sources. Serial port interface 346 is coupled to modem 354, through which computer system 
320 receives data from and/or transmits data to external sources. Alternately, modem 354 
jh can be a Data Over Cable Service Interface Specification ("DOCSIS") modem or digital 

a 

^ subscriber lines ("DSL") modem that is connected to computer system 320 through an 

d£ 2 g w § 

rtSl^^aj appropriate interface. However, as depicted in Figure 3, serial port interface 346 and 

O I < gj H 5 

§ 3S o 1 1 modem 354 facilitate the exchange of data with remote computer system 393 via link 352. 
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S t S 5 j Link 352 represents a portion of a network, and remote computer system 393 represents a 
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w node of the network. 



O [0061] While Figure 3 represents a suitable operating environment for the present 

invention, the principles of the present invention may be employed in any system that is 
capable of, with suitable modification if necessary, implementing the principles of the 
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present invention. The environment illustrated in Figure 3 is illustrative only and by no 
means represents even a small portion of the wide variety of environments in which the 
principles of the present invention may be implemented. 

[0062] Modules of the present invention, as well as associated data, can be stored and 
accessed from any of the computer-readable media associated with computer system 320. 
For example, portions of such modules and portions of associated program data may be 
included in operating system 335, application programs 336, program modules 337 and/or 
program data 338, for storage in system memory 322. When a mass storage device, such as, 
for example, magnetic hard disk 339, is coupled to computer system 320, such modules and 
associated program data may also be stored in the mass storage device. In a networked 
environment, program modules and associated data depicted relative to computer system 
320, or portions thereof, can be stored in remote memory storage devices, such as, for 
example, system memory and/or mass storage devices associated with remote computer 
system 383 and/or remote computer system 393. Execution of such modules may be 
performed in a distributed environment as previously described. 
j>m [0063] The present invention may be embodied in other specific forms without departing 

3 



[Jj from its spirit or essential characteristics. The described embodiments are to be considered 

s*h 1 1 1 Is = in all respects only as illustrative and not restrictive. The scope of the invention is, 
therefore, indicated by the appended claims rather than by the foregoing description. All 
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3 changes that come within the meaning and range of equivalency of the claims are to be 



embraced within their scope. 



O [0064] What is claimed and desired secured by United States Letters Patent is: 
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